Sprawdzanie podatności na SQL Injection
Dzisiaj kolejny wpis z bezpieczeństwa stron. Poruszę kwestię sprawdzania, czy nasz skrypt jest podatnych na tego typu ataki oraz w jaki sposób można masowo sprawdzać próby ataków (formularze, ciasteczka, sesje i ingerencja w adres strony).
Do popełnienia tego wpisu zainspirował mnie artykuł w najnowszym numerze hackin9 6/2009 (49). Pierwsze wrażenie jakie na mnie zrobił artykuł „Metodyka ataków SQL Injection” to, że będzie powtórka z rozrywki. Znowu będą przykłady brane żywcem w z Wikipedii. We wstępie tak niestety było.
Testowanie ręczne podatności na tego typu atak trochę mija się z celem. Trzeba wtedy sprawdzać:
- pola formularzy (te ukryte, jawne itp),
- ciasteczka,
- sesje,
- parametry przekazywane metodą GET.
Sprawdzenie tego wszystkiego będzie czasochłonne. Można to zlecić specjalistom lub skorzystać z dobrodziejstw Internetu i znaleźć darmowe aplikacje ułatwiające nam życie â fuzzery (ang. fuzzers, fuzzing). Pod tą tajemniczą nazwą â fuzzer
â kryje się program, który wprowadza losowe dane do testowanego programu. Te losowane dane są w odpowiedni sposób spreparowane â tzn. ich wprowadzenie może doprowadzić do pojawienia się błędu. W przypadku stron internetowych będą to np. błędy o niepoprawnej składni języka SQL, pojawią się informacje o polach, tabelach, typie bazy danych. Takie dane już mogą być pomocne dla Intruza.
W artykule są wymienione przykłady takich aplikacji pod SO Windows, którego już (na całe szczęście) nie posiadam ;). Jest natomiast podane rozszerzenie do FireFoxa, dzięki któremu można przeprowadzić taki test. Rozszerzenie sprawdza formularze - zamienia wszystkie checkboxy, selecty czy radio na pola tekstowe, dzięki którym łatwiej można coś wstrzyknąć. Rozszerzenie pozwala na prowadzenie własnych reguł.
Po więcej informacji teoretycznych odsyłam do czasopisma.
Komentarze 4
Pomysłowy programista mógłby napisać skrypt, który zamieni pola formularzy i będzie je testował na najpopularniejsze wstrzykiwane sql stringi. curl, regexp i godzina czy dwie pisania...
@up
Z tymi czasami w ile byście to napisali to niekiedy jest śmieszne.
W 5 minut najlepiej.
Zastanawia mnie jak błędy składni SQL i typie bazy mogą pomóc intruzom się dostać do naszej bazy danych...? przecież haker musi poznać hasło do naszej bazy danych ,a fakt że wie jakie są w niej pola w tym mu raczej nie pomoże ;)
Irek - nie masz racji. jezeli masz mocno spieprzony kod na stronie to mozna np. wyciagnac liste uzytkownikow jak juz znasz nazwe tabeli, czy tez - wyczyscic wszystkie dane z bazy - niepotrzebne Ci haslo bo to jest zapisane w pliku config.php na serwerze i np. formularz ktory 'obrabiasz' jest w pliku, ktory includuje config'a